A universal terrestrial radio access network (UTRAN) is a collective term for Node B's and radio network controllers (RNCs) of a universal mobile telecommunications system (UMTS) radio access network (RAN).
A RNC controls a given portion of the UTRAN. For example, the RNC manages UTRAN resources such as the downlink (DL) or forward link power transmitted by the Node Bs; the uplink (UL) or reverse link interference perceived by the Node Bs; and the hardware situated at the Node Bs.
With respect to a certain connection between the RAN and user equipment (RAN-UE connection), an RNC can either have the role of a serving RNC (SRNC) or a drift RNC (DRNC).
If an RNC is a serving RNC (SRNC), then the RNC is in charge of the connection with the user equipment unit (UE). In this case, the RNC has full control of the connection within the radio access network (RAN).
A DRNC supports the SRNC by supplying radio resources (within the cells controlled by the DRNC needed for a connection with the user UE.
When a radio failure condition between the UE and SRNC occurs and the UE camps on a new cell controlled by a new DRNC, a call may fail unless SRNC-triggered automatic recovery is invoked. To automatically recover and avoid call failure, the radio resource control (RRC) connection between the UE and the SRNC should be re-established through the new DRNC and its corresponding Node B.
Section 7.5.1.1 (Radio Resource Control (RRC) Connection Re-establishment) of the 3rd Generation Partnership Project (3GPP) standards document 3GPP TR 25.931 describes the manner in which to perform automatic recovery from the above-described radio failure condition. Recovery requires transmission of a cell update confirm (CUC) RRC message from the drift RNC (DRNC) to the UE over a common control radio channel (CCCH).
If both the UE and the Node B controlled by the new DRNC support the Enhanced Forward Access Channel (eFACH), then the DRNC sends the CUC RRC message to the UE through the Node B via the eFACH CCCH. In this case, the message is transmitted via the High-Speed Data Signaling Control Channel (HS-DSCH).
If the Node B supports the eFACH, but the UE does not, then the DRNC transmits the CUC RRC message to the UE through the Node B via the FACH CCCH. In this case, the message is transmitted using a 3GPP Release-99 signaling transport channel.
To ensure that the DRNC provides the CUC RRC message to the UE on the proper forward access channel, the DRNC may provide the CUC RRC message to the UE via both the FACH CCCH and the eFACH CCCH. In this case, the DRNC remains unaware of the forward access channel capabilities of the UE. However, this methodology utilizes unnecessary radio resources.
Alternatively, the DRNC may associate the forward access channel capabilities of the UE with the existing call context controlled by the SRNC. Then, the DRNC retrieves the stored forward access channel capabilities for the UE as necessary, and sends the CUC RRC message to the UE on the FACH or eFACH accordingly. However, this methodology results in unnecessary complexity and performance impacts on the DRNC, which is forced to store UE information that it typically is not required to store and manage. Moreover, when the UE moves to a different cell associated with a different DRNC, the new DRNC is unable to retrieve the existing call context, in which case the DRNC is forced to create a new call context, resulting in two contexts: one in the old DRNC and one in the new DRNC. As a result, the SRNC must manage duplicate DRNC call contexts for the UE.